1999/10/3 3:51
別件の方が忙しくて、こっちの方に手が掛けられない。もしかしたら今月は全然
進まないかも(;_;)
取り敢えず今日はリハビリを兼ねて、ソース公開に向けてFIXMEを埋め込む作業
をした。あと、68030以降のキャッシュ問題について、loader.rの初めで全面的
にキャッシュを禁止して、改めてCPUに合わせてキャッシュの設定を行うと言う
方針だけは決めた。ただ、暫くはキャッシュ禁止状態で使用することになるだろ
うけど、ソース公開したら誰かが対応してくれるだろうと言うことで（笑）
でもって、なんでキャッシュ禁止にするかと言うと、マシンによってキャッシュ
の状態がマチマチな可能性があるから。例えば、X68030や060turboみたいに
IPL-ROM上にキャッシュ制御のコードがあると、既にキャッシュONで制御が渡っ
てくるかも知れない。逆に、Xellent30(s|PRO)やJupiterなんかだとROMは元のま
まなのでキャッシュはおそらくOFFだろうから。あ、Xellent30の場合、SRAMに専
用プログラムを入れておくとキャッシュONで立ち上がるかも。と言う訳で、個別
に対処するのは大変なので、取り敢えずその辺の設定は無視してキャッシュOFF
で起動することにする。どうせ立ち上がって仕舞えば、キャッシュ制御は自分で
やらないといけないのでこれでも問題無いハズ。もちろん、SRAMを見て改めてキャッ
シュの設定はやるつもり。（作業優先度は低いけど）
1999/9/26 23:36
しばらく間が空いてしまった所為かだいぶ忘れて仕舞っている。今回独自でIPL
を作成したのでloader.rの$c0000への再配置なんかせずに直接$c0000へ読み込め
ば良いことに今更気が付いた。この対処はそれ程手間ではないので、まずはそこ
から直していくことにしよう。
1999/9/13 1:58
あれ？CPUタイプのチェックルーチンでMC68000と認識された時の、分岐先の最後
がrtsで終わってないぞ（爆）これだと、そのままデータ領域に突っ込むのでむ
ちゃくちゃ危険なんですけど(^^;;;;;
って事で速攻で直しました。あと、これまで対応してなかったMC68020とMC68060
もちゃんと区別するようになったはずです。(NetBSD/X68kのソースを参考にしま
した)
あと、これまで適当に処理している部分が後で判るように、「FIXME」と言うコ
メントを少しづつ埋め込む様にした。と言うか埋め込み始めた。この辺もソース
公開に向けてぼちぼち整理して行かないと駄目だな。
1999/9/8 1:13
なんと言うか、何処から手を付けて良いのか迷ってしまうほど、やらないといけ
ない事が多すぎて結局、殆ど手を付けてなかったりする。取り敢えず、タスクの
ローカールヒープを持たせるために、boot.cnfの書式にヒープサイズのフィール
ドを追加。でもって、boot.cnfを読み込むloader.r側も対処した。
今のところ本人の希望として今後実現したい機能を上げておく。出来れば、最初
の幾つかは次回のリリースに含みたい。
・タスクローカルヒープ
・プリエンプティブなタスク切り替え
・ランデブ機能（name.srvの様な特に非同期動作を必要としないものはこっち
に置き換えたい）
・humanfs.srv
・タスク起動
・P-thread
・ソースの公開
・key.drvのネイティブ化
・text.drvのネイティブ化
ただ、例によってそううまく事が運ぶとは思えないので、実は単なる覚え書きか
もしれない(^^;
1999/9/6 1:51 LEVEL 3
loader.rのタスクの起動部分でポカミスを発見。ポインタのポインタでないとい
けない部分がポインタになっていた。せっかくgccが警告を出してくれているの
に、気が付かなかったとは、我ながら情けないっす。これは直したお蔭かどうか
ははっきりしないもののウチのXellent30マシンで起動するようになった。
と言うか、試験用に使用していたEXPERTの電源が死亡してしまった。フロントス
イッチを入れたら「バシッ」とか言ってヒューズが切れてしまったので、そのマ
シンでは確認出来なくなってしまったのです。このEXPERTには満開製作所のATX
電源キットを使用して250WのATX電源を接続して有ったのっだが・・・。
250Wの電源でヒューズが飛ぶとはどういう状況なのだろう？もしかして、何処か
ショートしているのだろうか？ちょっと心配である。
と言う訳で、暫くは（別の要因もあるけど）開発効率が下がると思われるので、
ここでリリースすることにする。色々やり残しは有るが、少しづつ進歩している
（ハズな）ので暖かく見守って欲しい。
1999/9/3 1:08
あーあ、９月になっちゃった。なんだか、ウチのXellent30マシンでも動かない
ので、68040や68060マシンでも動かないんだろうなぁ。
（因みに68000マシンでは動いてます）
とりあえず今日は、console.srvで画面切り替え時に無条件で１画面分を再表示
させていた部分を、文字の有る部分だけに最適化する処理を加えてみた。おかげ
で、画面切り替えが前よりはキビキビと動くようになった。LEVEL-2とはあんま
り変わってないけど、そろそろリリースするかな。
1999/8/30 0:32
今のところ、MC68030以降での動作不良だが、やっぱりキャッシュ周りの様な気
がする。一応、キャッシュの管理をもう少し細かく出来るように関数を分けてみ
たのだが、中身はまだ出来てなかったりして（笑）
所で、気になったのが、68040や68060を登載したマシンの場合、マシン起動時に
IOCSコールはキャッシュに対応しているのだろうか？
Humanの場合でも、IPLがHUMAN.SYSを読み込むのはIOCSを使う訳だから、キャッ
シュは制御（OFFにするとかクリアするとか）されてなければちゃんと動かない
気がするんだけど・・・。
1999/8/28 5:03
これまで結構煩雑だったインストール方式を改善した。基本的にはこれまでと変
わらないのだが、FDのイメージファイルを使用する様にしたので、若干アーカイ
ブのファイルサイズが大きくなってしまった。まぁ、今後コマンド類が増えてい
けばそれ所の騒ぎじゃないので問題無かろう（それより、この開発記の大きさの
方が問題有るかも）
さて、区切りも良いことだしここらでLEVEL-3のリリースをしようかなぁ。それ
とも、今一番CPU時間を浪費しているキーボードドライバをネイティブに改善し
てからの方が良いかなぁ。どっちにしても、もう寝よう。今日オフが有るし。
1999/8/26 0:59
昨日やり残したIPLは、思ったよりあっさり動いてしまった。FDの直接読み込み
と書き込みツールは既に有るので、次回のリリースからはフォーマットしたFDを
準備してもらって、FDイメージを書き込むだけでブートディスクが作成出来るよ
うになるはずである。これで、FLOAT2.drvを除いて全部自前で揃えたことになる。
あと、MC68030以降で動作不良の恐れの有る部分を発見。それは、割り込みベク
タを設定している部分なのだがIOCSを使わずに、直接アドレスを書き込んでいる。
割り込みベクタの変更は一種の自己書き替えに相当するので、キャッシュをフラッ
シュしてやらないとコードキャッシュやデータキャッシュのコピーバックが残っ
ていると古いアドレスに飛んでしまうと考えられる。これで、前回動かないと言
われた68060マシンで動いてくれると良いのだけれど。
1999/8/25 0:48
だいぶ安定しては来ているのだが、なぜかMC68030マシン（Xellent30s）だとお
かしな挙動を示してしまう。特別、MC68030で問題になるような部分はないハズ
なのだが・・・もう少し調べてみないとだめだな。
でもって、いきなりだけどIPLを書き初めてしまった。それもC言語で（爆）FDD
専用ではあるが、なんとか512byteに納めることが出来た。って、出来上がって
からフト思ったのだが、もしかして1024byteまで使っても良かったのかな？
まぁ、動いているみたいだから良いや。でも、まだloaderの読み込みまで行って
なかったりして（動いてないとも言ふ）
なんとか、この辺の問題を解決して9月頭頃には次のリリースをやりたいもんだ。
1999/8/24 2:19
FIFOオーバーフローの改善に成功。まぁ、判ってしまえば至って当然のことな訳
だけど、そこに行き着くまでがなかなか難しい物なのである。まぁ、それが楽し
いとも、プログラミングの醍醐味とも言うんだけど（笑）
で、何をしたのかと言うと、asm("stop #$2000")の１行を追加しただけだったり
して。まぁ、追加した場所がアイドルループの部分でUnlock()、Lock()と連続し
ている所要するに以下の部分な訳だ。
while(1){
Unlock();
asm("stop #$2000"); /* これがミソ */
Lock();
if( (task=(volatile TASK_INFO*)_lnkRDY.top) ){
・・・・
}
} /* end of while */
まぁ、良く見てみれば、割り込みが受け付けられる時間が極めて短い事に気が付
くハズだけど、こんな事に何日も費やしてしまう辺り、まだまだ修行が足りない
と言う事なんだろうなぁ。
1999/8/23 1:28
なんとかdly_tsk()を使った状態でも暴走しないようになった。原因は、プリエ
ンプティでないのに、割り込み処理で_currentTaskを変更してしまったために、
実際のコンテキストとカレントタスクとの整合性が取れなかったためにおかしく
なっていた・・・と思われる。そろそろ、プリエンプティブで無い事に由来する
弊害が目だってきたので、もう少し安定したらプリエンプティブ部分も実装する
ことにしよう。今、気になっているのは割り込み処理のFIFOオーバーフローなん
だが、相当数がバッファ・オーバー・フローで失われている(^^;;
これの原因がIOCS処理部分でのdis_dsp()/ena_dsp()間の割り込み処理禁止時間
が長い所為ならデバイスドライバをネイティブに置き換えることで改善出来るハ
ズなのだが、どうなんだろう。あ、そうそう。dly_tsk()でキー入力の監視を行
うようになったのでCPU稼働率はかなり激減した。少しはマルチタスクらしくなっ
てきたかな？
1999/8/19 1:45
昨日動いたと思ったら、デバッグ用にdly_tsk()をrot_rdq()にしたままの状態だっ
た。これじゃ動いて当たり前（爆）と、言う訳でdly_tsk()にすると前よりまし
になったものの、条件によって動きかたがマチマチになった。console.srvまで
で止まる時もあれば、pshの起動後コマンドを受け付けてから止まることもある。
この症状は間違いなく割り込み関係だな。明日もうちょっと調べてみよう。
1999/8/18 1:40
昨夜マシンの電源を落とした後に、フト完全なIdle状態から割り込みによりReady
タスクが発生した時に問題が有ることに気が付いた。でもって、今日試した見た
ところdly_tsk()がちゃんと機能するようになった。あと、各プログラムのLEVEL
管理が判らなくなりそうなので、リリース毎の各プログラムのLEVELを記録する
様にした。
1999/8/17 0:09
おおっと。開発記の記録を忘れてた。ほんとだぞ。なんにもやってなかった訳じゃ
なくて、単に記録を忘れてただけなんだから、間違えないように（笑）
で、何をやってたかと言うとdly_tsk()が無効になってた（これの所為でキー監
視タスクが待ち状態にならなくてCPU時間を浪費してた）のを修正しようとして
ました。んが、どうやらシステムのLockがうまく行ってない様な気がする・・・
このバグは根が深そうで、なかなか進展しないのです。困ったこまった。
1999/8/6 20:52
ガビーン！！マルチコンソールにしてから、やけに表示が遅いと思ったら、後
から追加したバッファリング処理が働いてなかった。どうりで遅い訳だ。バッファ
リング処理が動くようになると、マルチコンソールを入れる前とほぼ同程度の速
度になった。まぁ、これ位なら我慢出来るだろう（笑）
更に、割り込みFIFO超過破棄数があまりにも多すぎる・・・。それ以前に遅延
処理の方が多いのも問題だなぁ。って事で色々と調べてみたところUnlockされて
なひ（爆）そこを直したところ、多少は改善されたもののそれでも遅延数の殆ど
が破棄されている。他にもなんかあるのかなぁ。
1999/8/5 1:04 LEVEL 2
なんか本能の命じるままにコードを書いてたらfdd.drvが出来てしまったらし
い（笑）まぁ、IOCSベースなので簡単に出来て当たり前なんだけど。やっぱり、
調子良く進むと気持ち良いっす。でもって、何を血迷ったのかWWWページを開設
することにしてしまった。相変わらず行き当たりバッタりではあるが、いつもの
事と言うことで。ちなみにアドレスはやたら長ったらしくて
「http://www.geocities.co.jp/SiliconValley-PaloAlto/7276/」でふ。
そのうちこのPECLSやら、過去のフリーソフトなんかも載せる予定だが、4MBなん
てあっと言う間な気がしないでもないぞ。それ以前にHTMLが判らないからそっち
の勉強が先かな。
1999/8/3 1:15
ついにマルチコンソールが稼働！！ ただし、かなり手抜きな部分が多いので
洒落にならないぐらい遅いのだが。原因は、1文字毎にパケットを組み立てて
text.drvに送っているからだと思い、バッファリングをする様にしてみたのだが、
改善は見られなかった・・・？？？
と、言う事は、仮想画面の描画処理が思ったより重いのが原因のようだ。まぁ、
デバッグ用のコード入れまくりなので当然と言えば当然なのだが、text.drvの出
力がROMのIOCS（爆）と言うのも無関係ではないだろう。いずれは改善すると言
う事で。
そんな事よりもシステム起動時の画面出力が最初のコンソール画面に引き継が
れないので結構違和感が有る。これを解決するためにはloaderに取り合えずの
text.drvタスクを組み込むと言う手が考えられる。ただ、loaderの自己消滅と関
連して結構めんどくさそうだなぁ。
1999/8/1 0:02
あぁ〜〜あ。8月になっちゃった。L-2のリリースを7月中にと思ってたのに・・・
で、やっぱり問題はマルチコンソールだったりする。前回動かなかった原因は、
情けないメモリーリークで有ることが判明。しかし、いまだpshのプロンプトま
でたどり着けない。キー入力も受け付けないところを見ると、表示だけの問題と
言う訳でもなさそう。どっちにしろ、もう暫く掛かりそうなので、L-2のリリース
を8月中と言うことにして、fdd.drv辺りとhumanfs.srv、exec.srv周りも盛り込
んでみようかな。って、それは欲張り過ぎか(^^;
1999/7/26 23:28
うーむ。console.srvのマルチコンソールを取り敢えず作ったけど全然動かん
な。まぁ、いきなり動いたらそれはそれで気味悪いけど（笑）あと、console.srv
に連動してtext.drvのリクエストコードも多少手を加えた。もしかしたら、この
辺の修正をミスったのかも。どっちにしても色々いじったので何処が原因で動か
なくなったのか判らなくなったので、１つづつ地道にチェックして行くしかない
かな。できれば、今月末に次のリリースを行いたいのだが・・・
1999/7/21 1:53
なんか日にちが開いてますが気にしないように(^^;それはともかく、取り敢え
ずではあるが、READYキューへの登録時に優先度を考慮する様にした。ただ、現
在の実装では全リストを対象に優先度を比較していくので、タスク数が増えると
キューへの登録処理に時間が掛かることになる。これはそのうち、優先度毎にリ
ストを作成する様にして処理の高速化を行う予定。
あと、console.srvにマルチコンソールをサポートするための仮想画面管理処
理を追加した。と、言うか追加している。現在の実装では１文字表示する毎に
text.drvに文字表示を要求するようになっているが、バッファリングし、文字列
として要求した方が効率は良いハズだ。ただ、出力先がtext.drvではなく、sio.drv
等のように低速の通信路を経由する場合は、１文字毎に要求した方が全体的な効
率は上がる可能性があるので、このバッファリングはオプションで切り替えられ
る様にしておいた方が良さそうだ。
あ、そうそう。先日実装したref_tsk()を使う物をpshに組み込んでテストしな
いといけないなぁ。
1999/7/15 1:33
今日は特になにかを作ったと言う訳ではない。ここ数日の変更に対して実際に
動作するかを確認した。チマチマしたバグを取って、なんとか動くようになった
のがこの時間なので、今から何かすると言う訳にもいかない。
話しは変わるが、なんとかPC-UNIX上でクロス開発できないか調査中。実行ファ
イルの形式をELF形式に出来ればなんとかなりそうなんだけど、ELFのリロケータ
ブルフォーマットってHuman68kの.xファイルのリロケート情報みたいな物なんだ
ろうか。使えそうならローダーの変更だけで移行出来るのだが・・・
1999/7/14 1:43
name.srvが管理する情報フィールドをID×2からID×4に拡張した。
あと、参照系のシステムコールを幾つか実装しようと思ったけどref_tsk()だけ
で力尽きてしまった（笑）残りは後日と言うことで。
「今回の実装コール」
ref_tsk()
1999/7/13 1:33
なんかディレクトリィを深く掘った所為か起動に時間が掛かるような気がする
ので、loader.xにディレクトリィキャッシュを付けてみた。気の所為程度は改善
されたような気がする。
マルチコンソールのために、key.drvのrawモードでシフト状態も通知する様に
し、console.srvにコンソール切り替え機能を実装。と、言うかconsole.srv自体
には既にマルチコンソールの管理自体は入ってたりする。単に切り替え機能だけ
実装してなかっただけだけど（笑）
1999/7/12 0:41
気が向いたのでMC68030以降に対応してみた。対応と言ってもtrap周りの処理
で例外フォーマットも考慮する様にしただけなので対した手間じゃ無いですが。
ただし、今後プリエンプティブなタスク切り替えを実装した場合は、更に要注意
なので、気を付けねば。
あと、先日実装したシステム情報のシステムコールのデバッグを行った。まだ
ちょっと怪しい値を返しているような気もしないではないが、なんとか動くよう
になった。
MC68030以降でも動くようになった事だし、マルチコンソールを実装したら次
のリリースをするかな。
そうそう。ふと思い付いてITRONのWWWを見てきたらITRON4.0の規格書が出てる
ぢゃないですか。う〜〜〜む。これは、なんか適当なタイミングで3.0から4.0へ
移行しないといけないかな。ざっと見たところオブジェクトの動的確保周りが規
格に取り込まれたようだ。
1999/7/10 1:6
割り込みからのシステムコール周りを整備。でも、まだ割り込みからのシステ
ムコールは１つも実装してなかったりする（笑）
Makefileを充実。これまで個別のディレクトリィまで降りていってメイクして
いたのを上の階層からgmakeすることで下の階層全てをメイク出来る様にした。
でも、全部とかやると時間掛かるんだよな。
P-Threadライブラリだけど、イベントフラグだとカーネルの資源を消費するの
で、slp_tsk()、wup_tsk()で実現する様にした。だって、カーネル資源を使うと、
タスク終了時に返却しないといけないから面倒なので。やっぱり、ITRONは組み
込み向けだけあって、動的なタスクの管理関係が弱いなぁ。
1999/7/8 2:15
将来の標準ファイルストリームの事を考えてname.srvが管理する情報をIDから
FileHandleに変更した。これにより、１つの名前でIDを２つ保持出来るようになっ
た。それに伴って、key.drvのキーイベントにrawモードとcookieモードで別のパ
ケットを返す様にした。こうすることで、通常は別のタスクからの文字列表示を
そのままキー入力として受け入れることが出来るようになるので、パイプ処理が
実現し易くなるハズ。
前回書いたシステムコール処理関数の戻り値の設定をちゃんと行う様にした。
あと、せっかく計測する様にしたCPU稼働率が見られるようにシステムコールを
追加した。
それとP-threadだが、このライブラリにはC-threadと異なり明示的にライブラ
リを初期化するコールが無いようだ。これでは、ルートスレッドに対してスレッ
ド管理領域が確保されてないので色々と面倒な事になりそうだ。
なので、P-threadを使う場合は、別のスタートアップルーチンを使うような小細
工が必要だろうと思う。まぁ、たいした手間じゃ無いけど。それにしても、この
「開発記」はサイズが増えるのが早いなぁ（笑）もしかしてプログラム書くより、
こっち書く量の方が多かったりして（うっ・・・笑えん）
「今回の実装コール」
ref_sys()
1999/7/5 2:38
P-threadの実装上必要になったのでイベントフラグの実装を行った。そう言え
ば、各同期オブジェクトには初期化用のパケットが有ったけど、今のところ殆ど
無視していたりする、この辺もちまちま作り込んで行く必要があるな。
あと、システムコール処理関数のreturnでシステムコールの処理結果を返すの
は問題があることが判明。この修正は結構手間取りそうなので、そのうち気が向
いたら対応しよう。どうせ、問題が出るとしたらexd_tsk()の場合ぐらいなので、
急ぐ必要はないや。
あと、気になっているのが68030以降への対応。多分、trap処理周りだけだと
思うのだが後回しになってたりする。そんなに難しくないハズなので、とっとと
片付けてしまった方が良いかも知れないゾ。
「今回の実装コール」
cre_flg() del_flg() set_flg() clr_flg() wai_flg()
1999/7/3 1:03
フト思い付いてカーネルのCPU稼働率を検出する処理を入れてみた。まぁ、ア
イドルループの前と、レディタスクの発見時との時間から空き時間を集計するだ
けの簡単な代物だけど、カーネル稼働時間と比べればシステムの負荷が算出出来
るので結構使えるかも。って、そのためにはその情報を引き出すシステムコール
が必要な訳だけど、これはそのうち実装しよう（笑）
P-threadのライブラリをぼちぼち作り始めた。基本的なシステムコールが揃っ
ているので、これらを組み合わせれば結構簡単に実装出来そうだ。ITRONではス
レッドと言う概念がないので、システムコールレベルでは、タスクもスレッドも
同じだけど、OSとして見た場合は全く別物として管理しないといけないので、こ
の辺の実装が頭の痛いところだ。一応、exec.srvがその手の管理を行う予定。
そうそう、ITRONにはスレッドもタスクも同じなので、計らずも１対１モデル
になるのであった。ヂュアル・プロセッサ（POLYPHON!?）なら効率的に動作する
ハズだ。カーネルが対応してればだけど。
1999/7/2 1:13 LEVEL 1
予告通りLEVEL-1のリリースである。ホントはマルチコンソールまで実装して
からリリースしたかったけど手間取りそうだったので、次回に持ち越しとした。
取り敢えず、今回のリリースの目玉は、pshの全ての入出力がconsole.srv経由で
keyboard.drvとtext.drvを使用して行われることなのだ。依然、IOCSベースでは
あるが、I/Fさえ決めておけば本当のドライバと差し替えても問題無いハズなの
で、大きな前進と言える・・・かな。
今後の予定としては、console.srvのマルチコンソールとか、fdd.drv、exec.srv
とか色々有るので、考えると気が遠くなるので敢えて考えないことにする(^^;;
1999/7/1 3:04
ホントはLEVEL-1は6月中にリリースしたかったんだけど、コンソールサーバー
周りがまだ未整理なので、今週末まで延期することにした。それ以前に全然前回
と見栄えが変わってないのが情けないっす。まぁ、内部的には結構かわったんだ
けど・・・。
でもって、psh内でキー入力をIOCSコールで行っていたのをconsole.srv経由の
keyboard.drvで行えるようになった。とは、言ってもkeyboard.drv内では、未だ
にIOCSを使ってたりするのだが(^^;
後は、画面の表示の方もconsole.srvを経由してtext.drvに行わせるように出
来たら取り敢えずリリースしようと思う。
あ、そうそう。先日のselect()の件だが、ITRONの仕様書をひっくり返したと
ころ、dis_dsp()と言うコールが有ることを発見。これは、一時的にタスクの切
り替えを遅延する（禁止する訳ではない）ものなので、一種の排他制御が行える
ようだ。これを使えばいちいちセマフォを使わなくても気軽にロックが掛けられ
る訳だけど、ネストは出来ないそうなので、やっぱりセマフォでやった方が良さ
そうだ。
「今回の実装コール」
dis_dsp() ena_dsp()
1999/6/30 3:41
う〜〜む。困った。コンソールサーバなんだけど、こいつは、アプリとデバイ
スドライバとの両方からのメッセージを同時に待つ必要が有る訳なんだな。だけ
ど、ITRONにはUnixで言うところのselect()が無いので、複数のメイルボックス
に対して待ちに入ることが出来ない訳で困ってるのだ。まぁ、むりやり複数のス
レッドを立ち上げて個別に待ち状態にはいる手も有るけど、複数のメイルボック
スに対して待ちが出来るシステムコールを独自で追加しようかと考え中。
一般的にはメッセージパケット中に発信元やパケット種別を入れることで区別
する訳だけど、それだとシステム全体での整合性を保つのが難しいので、独自仕
様を追加する方針も考えている。さぁて、どうするかなぁ。
ま、動くことが先決なので、別スレッドで取り敢えず実装しておこう。
1999/6/28 1:26
昨日色々手を入れ、コンソールサーバーもコンパイルが通るようになったので、
今日は試しに動かしてみた。すると、ネームサーバーの起動で止まってしまうぢゃ
ないの(;_;)デバッグ出力を頼りにあちこち調べてやっとの事で、先日やった排
他制御をシステムコール入り口に移動した時のエンバグである事が判明。
まぁ、今日は雨だったとは言え、このバグで一日潰れたのはやっぱり情けない
なぁ。精進せねば・・・。
1999/6/27 4:10
タスクの状態としてこれまで設定していたTTS_RUNを付けない様にした。どう
せ、_currentTaskで判るし、ref_tsk()（まだ作ってないけど）で小細工すれば
済むのでわざわざやる必要もないだろう。でもって、セマフォを実装した。全然
関係無い話しだけど、何を勘違いしたのかセマフォの綴をsemafoと書いてたけど、
実はsemaphoreが正しいようだ。と、言う訳で今回からはsemaphoreとなっている
のでみんなも気を付けよう。
今回のセマフォの実装で最低限のシステムコールは実装出来たことになるのか
な。今後はサーバーやドライバ等の作成で必要になった段階で順次実装していく
ことになるかな。これはきっと近代的なオン・デマンドとやらに違いないぞ（笑）
「今回の実装コール」
sig_sem() wai_sem() preq_sem()
1999/6/25 0:16
ちょっとバテ気味。今日はあんまり大したことやってない。取り敢えず、割り
込みに対する排他制御をチマチマやるのをやめて、システムコールの出入口で一
括して行う様にした。ほんとは割り込み処理の応答性を考えるとチマチマやった
方が良いのだが、現在の開発段階ではめんどくさいだけなので、この手の最適化
は後の楽しみに取っておくことにする。
関係無いけど今年の夏はなにやら忙しくなりそうだ。本業の仕事と、アルバイ
トのソフトの仕事、そんでもってこれの開発に、週末にはキャンプツーリングと
まぁ、その他色々と・・・。でも、私の思考もリアルタイムなので、優先度に従っ
て進める訳なので問題無いかも。当然、一番低いのは本業なのだ（笑）
1999/6/22 0:17
割り込み処理の中身を実装した。これにより、dly_tsk()が使えるようになっ
た訳なんだけど、暫定処置としてIOCSを使っている部分が多いため、プリエンプ
ティブなタスク切り替えは暫くお預けだな。
例によって、割り込みでのタイムアウトチェックは非効率的な実装になってい
る。余力が出来たらリングバッファを使った、より効率の良い方式に修正せねば。
あと、昨日作った時間関係のシステムコールをテスト。pshにdateコマンドを
追加して連続表示させてみたところ、どうやらそれなりにちゃんと動いているら
しい(^^)
「今回の実装コール」
dly_tsk() rot_rdq() sus_tsk()
1999/6/21 2:43
カーネルの時間関係のシステムコールを実装する前に時間に関する処理を組み
込んだ。それにしても、ITRONの仕様だとSYSTIMEは48bitと中途半端でちょっと
使い辛いなぁ。64bitならlong longで楽なんだけど。
取り敢えず、ライブラリとしてSYSTIMEとstruct tmの相互変換関数を追加した。
まぁ、これは後々のPOSIX準拠(するのか!?)のための布石なんだけど。
あと気になるのは、カーネルの周期割り込みをタイマーDで行っているが、こ
れは将来的にタイマーCに変更したい。その為には、FDDドライバとかの周辺を整
備しないといけないけど。それと、現在のget_tim()で得られる値は、カーネル
起動時間から割り込みでカウントした時間なので、実際のRTCの値と違う可能性
がある。この時間誤差の補正をどうするかが問題。
構想としては、１時間毎に補正するとして、RTCより進んでいたら割り込みを
幾つか無視することで、遅れていたら割り込み時の処理を複数回行うことで合わ
せる様にしたい。んが、こんなのはも〜〜〜〜っと他の所が出来てからだな（笑）
「今回の実装コール」
get_tim() set_tim()
1999/6/17 1:40
システムコールの処理内に割り込みとの排他制御を組み入れた。あと、排他制
御中の割り込み処理でのシステムコールを保持するFIFO処理を作成。っていうかー
pecls libraryのソースから殆どそのまま持ってきた。ちょっと心配なのは、ヒープ
の確保や解放も排他制御のLock()、Unlock()内に有ることだ。メモリーの確保時
や解放時には場合によっては結構な時間が掛かることが考えられるので、どうし
たもんかなぁ・・・。
それと、コンソールサーバーの考え方に付いて、１セットの入出力デバイスに
対して１つのコンソールサーバーを起動することにした。これは、マルチコンソール
を考えると妥当な線だと思うのだがどうだろう。
そうそう、ライブラリを追加したのを忘れるところだった。ネームサーバーに
対する登録と問い合わせの関数をliblow.aに追加した。(MailboxINameRegist、
MailboxIdGet)
1999/6/14 0:30
コンソールサーバーに関しては、まだ考えがまとまらないので、気分転換に他
の部分をちょこちょこいじった。取り敢えず、ネームサーバーについては現地点
で一通りの機能を実装したので、これからしばらくは手を加える必要は無いだろ
う。あと、ネームサーバーと実行サーバーリクエストで、返答先IDが入ってない
とエラーにしていたのを返答が必須でないリクエストの場合は正常として扱う様
にした。
それにしても、あれやろうこれやろうと言ってるわりに、それとは関係無く適
当に進めてる気がするなぁ（笑）まぁ、それだけやることが残っていると言うこ
とで、勘弁してちょんまげ（死語）
1999/6/7 23:50
そろそろコンソールサーバーも作りたいので、入出力のやり取りを考えてみる
が、どうもうまい手が思い付かない。少なくとも、マルチコンソールを実現する
ために、仮想VRAMはコンソールサーバー上に持つ必要があるので、エスケープ
シーケンスの解析はコンソールサーバーでやらないといけないのは確かだ。
あとは、端末デバイスファイルを使った標準入出力の割り当て手順を考えない
といけない。この辺をうまく取り決めておけば、りダイレクトやパイプの実現も
手軽に実現出来るハズである。
1999/6/5 20:18
結構間が開いているが、その間何もしてなかった訳じゃないぞ（笑）サーバーや
ドライバを作成してて、マルチスレッドを実現するために、それぞれでcre_tsk()
とかやっていると、実行サーバーとの絡みも有って結構めんどくさい。
なので、その辺の問題をまとめて扱えるようにスレッドライブラリの導入を検
討中である。もちろん仕様はPスレッドで有る訳で、その手の資料を勉強中だっ
たりする。ただ、この本を読み終わるまで開発がストップするのもアレなので、
そろそろ割り込み周りでも実装しようかと考えている今日この頃。
PECLS Libraryの時にも手間取ったけど、カーネルの排他制御と割り込みから
のシステムコールによるタスクの起動は、明かにアクセスする領域がバッティン
グするので、リアルタイム性を尊重するためにも割り込み禁止期間は短い方が良
い。なので、割り込みからのシステムコールをFIFOに貯める細工が必要になって
くる。
あと、割り込みからのシステムコールは、事実上別のtrap番号が必要なので、
その割り当ても考えねば。
そうそう、タスク毎のローカルヒープサイズの指定方法も考えておく必要が有
るなぁ・・・。残件は上げ始めると切りがないのでこの辺にしておうこう(^^;;;
1999/5/26 4:54
次はファイルサーバーとか言いながら、キーボードドライバを作成した。最低
限の機能は実装したものの、このドライバにアクセスするタスクがまだ無いので、
ちゃんと動くかどうかはまだ不明。それにしても、毎回色々直しているので修正
履歴とか書けないのがちょっとアレだけど、まだ暫くはこんな感じかな。
と、言う訳でLEVELの割り当ては、有る程度安定するまでリリース毎になるの
かな。
サーバーリクエストのリクエスト先IDを廃止した。理由は、この情報を保持す
るのは問題無いが、boot.cnfのネームサーバーへ登録するID名称との対応を取る
のが難しいから。特に今後スレッドとかが出てくるとややこしくなるのが目に見
えているので、思い切って廃止した。お蔭で、サーバーソースはもちろん、ヘッ
ダーも修正することになったので、ローダーまで修正と言う・・・カーネル以外
殆ど全部に手を加える羽目になってしまった。
1999/5/23 1:28
まだ本腰は入れないけど、MC68000以降でも動作する様にするための手始めと
して、キャッシュのフラッシュ処理を書いた。あんまり手元に資料がないので、
自信はないけど、多分大丈夫だろう。68020、68030については、Motorolaの
「ユーザーズ・マニュアル」を、68040についてはBEEPs氏の「X68/040turbo」を
68060については、「Oh!X復刊一号」を参考にした。各著者の方々に感謝します。
メモリープール関係の処理を整理。これによりローカルヒープが扱えるように
なったハズ。あと、ついでにタスク関係の簡単なシステムコールも幾つか揃えた。
小さな事からコツコツとって事で（笑）
「今回の実装コール」
cre_mpl() del_mpl() ext_tsk() wup_tsk()
1999/5/21 2:33 LEVEL 0
pshのコマンドを作成。これで、ちゃんとサーバーに問い合わせて一覧情報を
取得するようになった。う〜〜ん。マルチタスク・システムっぽくなってきたぞ。
あと、ユーザープログラム（サーバー、ドライバも含むけど）の標準スタートアッ
プ・ルーチンをライブラリに入れる様にした。これで、main()は普通にargcと、
argvが参照出来るようになったし、malloc()、free()も使えるようになった。
ただし、まだローカルヒープが作成出来ないので、ライブラリの方はこの先手
を入れる必要がある。それにしても、ローカルヒープとマルチヒープとの組み合
わせをどうするかは今後の課題である。
ファイルサーバー作成の前に、実行サーバーをそこそこ片付けて¥junk辺りに
アップすることにした。知っての通り、システムの骨格どころか、背骨も出来て
ないので、ほ〜〜んとになんにも出来ないが、まぁ、反応を見ると言うことで。
1999/5/19 0:53
ついにネームサーバーが動作を開始。とは言っても、基本的な部分だけなので
そんなたいした事ではないんだけど（笑）
前回の記録から日数が掛かっているのは、ネームサーバー問い合わせでアドレ
スエラーになると言うバグの追求に手間取った所為だったりします。
原因は取り敢えず対処でpget_blk()内部で呼び出しているHalloc()のIDに0を
指定してしまっていたために、そのブロックが未使用と判断されていたと言う、
例によって情けないバグでした。こんな事で３日も悩むなんて、我ながら情けな
い・・・(T_T)
でもって、調子良く進み始めたので、実行サーバーのタスク管理部も少し作り
込んでみた。実行サーバーが本格稼働するためにはファイルサーバーの存在が必
要なので、まだまだだけど、タスク一覧とかメモリーの使用状況とかが有る程度
把握出来るようになったのは進歩したと言えるかな。
ネームサーバーについては、外部との接点が非常に少ないので、最低限の機能
は実装出来たことになる。実行サーバーのためにもそろそろファイルサーバー辺
りも作り始めるかな。
1999/5/16 3:25
ん〜〜む。バグが取れん。なんか、ネームサーバーの管理情報のアドレスがお
かしいらしく、止まってしまう。昨日まではpsh.xまで動いてたので、それ以降に
追加した部分に問題があるんだろうけど、幾ら見直しても判らない・・・
バグが取れない気分転換に、各ファイルの拡張子を以下のように整理した。
カーネル .knl
サーバー .srv
ドライバ .drv
アプリ (無し)
1999/5/15 4:14
ネームサーバーをもう少し身の有る物にした。まだ完全じゃ無いけど、先日作っ
たsnd_msg()とrcv_msg()も、幾つかのバグを取ることで動くようになったラシイ。
あと、PECLS標準シェルになるはずのpsh.xを取り合えずのチェック用として、幾
つかのコマンドを実装した。ちゃんとしたシェルとしての機能を持たせるまでは、
内部コマンドを色々追加して、それを使ってテストをするだろうから、最終的に
は作り直しになるかも（笑）
どっちにしろ、外部コマンドを起動出来るようになるためには、最低でも実行
サーバー、ファイルサーバー、ディスクドライバが揃わないといけないので、ま
だまだ、まだまだ、まぁ〜〜だまだ先なので今心配する事でないな。
1999/5/12 21:57
なんか、思ったより簡単にFLOAT2.drvが出来た。まぁ、DOSコールをIOCSコール
に置き換えて、KEEPPRをslp_tskに変えただけ（笑）なので簡単な訳だけど。ち
と、拍子抜け。とは言ってもタイトル画面が出るのを確認しただけなので、ちゃ
んと動くかどうかは、まだ判らなかったりして（笑）
他の部分が落ち着いたらその辺もチェックせねば。それはともかく、タスクの
起動自体は出来るようになったので、ちゃんとしたマルチタスクを行うためにも、
同期プリミティブの実装を開始した。最低限、メイルボックスとセマフォを実装
しておけば、かなりの事が出来るのでその辺を優先的に組んでいく予定。まぁ、
実際は優先度とか、プリエンプティブとか、割り込みとか、解決しないといけな
い問題がまだまだ山積みだったりする訳だけど、まずは動くことが先決と言う事
で、結構いい加減な所が残っていたりする。この辺も追々直していかないとね。
「今回の実装コール」
cre_mbx() del_mbx() snd_msg() rcv_msg() cre_sem() del_sem()
1999/5/11 22:53
動かなかった原因が判明。まぁ、例によってしょ〜〜〜もない事だった訳だけ
ど、一応書いておこう。一言で言ってしまえば、「リンク後の位置とリンカに指
定するファイルの順番とは必ずしも一致しない」って言うことであった。
ヒープ領域を確保するのに、サイズを指定したくなかったので、ラベルだけ定
義して最後にリンクすれば大丈夫だと思ったんだけど、そうは行かなかった訳。
やっぱり手抜きは良くないな。ちなみに、ROMデバッガのお蔭で原因を突き止め
ることができた。こう言う便利な物をROMに入れてくれてありがとね＞SHARPさん
1999/5/10 10:00
連休中はまぁ〜ったく手を手を付けてなかった。っても、サボっていた訳じゃ
なくて、ロングツーリングに行ってただけである。しばらく寝かせたので、例の
バグは小人さん（笑）が直してくれているかと思ったんだけど、そんなに甘くな
かったらしい。ん〜〜〜。なにが悪いんだろう？？？
1999/4/25 1:18
なんだか低レベル関数郡を関数毎に分けてライブラリ化したら動かなくなって
しまった(;_;)それも、どうやらローダー部分で動かなくなっているらしい（爆）
原因が判らんなぁ〜〜〜。怪しいと言えばヒープ関係の関数が、よりメモリー効
率の良い物に置き換えたので、これかもしれなひ。どっちにしろ、続きは連休明
けてからだな。
1999/4/24 7:20
ソースとかが結構増えてきたので、ディレクトリィ・ツリーを整理した。つい
でにローダーやカーネルで使っている低レベルライブラリも統合した。
あと、FLOAT2もver.2.01のラベルを参考にしたので比較的簡単にver.2.03の解析
も終わったし、ドライバにしちゃおっかな〜〜。
1999/4/23 6:30
エラーの発生原因はどうやら、スタック領域の問題だったらしい。取り敢えず
タスクを全てスーパーバイザーモードで動かすことで解決。ただし、ユーザーモード
で動かすことを考えると、スーパーバイザースタックの扱いは注意せねば。
なにはともあれ、色々適当に処理しているところはあるものの、もっとも基本的
なタスク処理は動くようになったと言う事で、嬉しいなっと。
1999/4/22 1:17
「エラーが発生しました」状態が続いてちょっと手詰りなので、例外割り込み
周りを付けてみた。場所自体は判るようになったけど、原因の方はさっぱり(;_;)
やっぱり、逆アセンブル表示位は出来ないと原因追求は難しいか・・・
「今回の実装コール」
get_pid()
1999/4/14 5:11
また夜が開けてしまった・・・。それはともかく、最低限のタスク起動コール
を実装した。タスクの切り替え自体もなんとなく動いているような気もするが、
ちょっち自信無し（笑）。
あと、取り合えずの処置としてpget_blk()とrel_blk()も実装してある。ヒープ
自体を生成するコールが無いので、グローバルヒープしか扱えないけど、これで
しばらくはもつはずだ。
FLOAT2についてだが、disって解析していたのが実は古いバージョンで有った
のが判明（涙）。なんと、ver.2.01だったのだ。手持ちで一番新しいのはver.2.03
なので、もう一度解析せねば・・・(;_;)
「今回の実装コール」
cre_tsk() del_tsk() sta_tsk() slp_tsk() pget_blk() rel_blk()
1999/4/12 4:48
よっしゃー！！システムコール第一号の実装が完了。動作もおっけー。とは言っ
てもget_ver()のみじゃタスクの切り替えもクソも無いので動いた内に入らない
かも。
まぁ、タスクからのシステムコールで、カーネル内のCで書かれた処理関数ま
での引き数の引き渡しに付いて確認出来たのは間違いないので、やっぱりメデタ
イぞ。
FLOAT2.drvの作成だが、カーネルの作成が順調なので、ローダーに組み込むの
はやめて、いきなりタスクにしちゃおっかなー。とか考えている。
元になるFLOAT2.x自体は既にdisってあり、Human固有部分を外せばそのまま行け
そうなので・・・
「今回の実装コール」
get_ver()
1999/4/10 6:10
うひひ。ちょ〜〜〜〜〜〜〜〜〜恥ずかしいバグを発見。これで、先日のシス
テムコールで止まってしまう問題は解決してしまった。なにが問題だったかは、
恥ずかしすぎるので、闇に葬る事にしよう。なにはともあれめでたしめでたし。
1999/3/28 1:37
なんとか、カーネルを読み込んで初期化出来るところまでたどり着いた。んが、
システムコールはやっぱり１つとして組み込まれてない。
どのコールを呼び出してもエラーしか帰らないようになってるのだが、このダ
ミー処理内で文字列を画面に表示(B_PRINT()で)しようとしたらエラーになって
しまった(;_;)
カーネルスタックの切り替えに失敗しているのだろうか？
1999/3/18 0:20
ついにカーネルの実行ファイルが出来た。ただし、システムコールは一切サポー
トしてないNULLカーネルだけど。それにしても、足りない物が随分あるなぁ（笑）
☆思い付くまま残件
・ローダー
・カーネルの幾つかのシステムコールが動かないと、必須サーバーが登録出来
ないので、ローダーの開発が進まない・・・
・FLOAT?.xの解析
・取り敢えずFLOAT2.xをローダーに組み込んでおけば、ローダーが常駐してい
る限りFEコールは使用可能になるな。ふふふ。
・そのうち、FLOAT2.xからFLOAT2.drvを作らねば・・・
・BOOT_INFOに載せる情報。
・カスタマイズ可能な項目
・メモリー管理方法
・全てグローバルヒープで行う？
・カーネルオブジェクトの管理には専用の固定長メモリー管理を使う？
・タスク用のローカルヒープも持たせる？
・スレッドの実現
・EXECサーバーで管理する？
・カーネルでサポートする？
・sta_tsk()で小細工する？
・タスク自体が軽いので不要？
・OSの構成
・カーネル
・FLOATドライバ
・EXECサーバー
・NAMEサーバー
・FATサーバー
・CONSOLEサーバー
・FDドライバ
・TEXTドライバ
・KEYBOARDドライバ
・RAMDISKドライバ
・シェル
1999/2/16
ローダースクリプトを解析して内部リストを構成することに成功。
まだ、Human上でのテスト実行ではあるけど、IOCSコールを使用してのHumanファ
イルのアクセスまでたどり着けたわけだ。
1999/1/1
何を思ったか、PECLS OSの開発を始める。とは言ってもいきなり動く物は何も
ないので、幾つかのディレクトリィを準備して、Makefileを書いて、使えそうな
ライブラリソースをかき集めただけ。でも、おそらくは長い開発の始まりなのは
確かなのだ。ほんとは、決めておかないといけないことが一杯有る訳だけど、そ
う言った細かいことの覚え書きのために、この開発記を書き始めることにした。
たぶん、絶対に不定期になるので日記じゃ無くて開発記である。お間違えの無
いように（笑）